The configuration and release management of group systems software, and in particular group application systems software in an account management system of a large banking entity, can involve software changes and deployment at both the global level and at the local level. For example, a global bank such as HSBC conducts business in 76 countries and territories around the world. These operations are managed in four geographical regions: the Americas; Europe; the Middle East and Africa; and Asia Pacific. Each of these regions encompasses multiple countries, and each country includes several strategic business units, or SBUs, which are HSBC's smallest business operating divisions. In order to address the needs of SBUs around the world, HSBC deploys mainframe-based “group systems” software applications. These software applications may be developed in-house, or may be based around commercially-available software packages which are supported by a vendor and enhanced by HSBC as necessary.
A difficulty in employing an account management system of the complexity and scope of the HSBC system is the amount of overhead that accompanies deployment of a complete copy of the system for each of the SBUs using the system. A complete copy of the software system may include, for example, source code, copybooks, and job control language for each of the software application components within the software system. In the majority of cases, much of the group application systems software is common for all SBUs, with only a relatively small amount of customization necessary for an application to effectively support an individual SBU.
Various approaches have been employed in the past in connection with software configuration and release management. An example of a computing system deployment planning method is disclosed in Tseng et al. International Patent Publication No. WO 03/098490, published Nov. 27, 2003, shown in FIG. 1, and incorporated herein by reference. The computing system deployment planning method of FIG. 1 is implemented using deployment planning system 10, which resides on a computer-based system that is networked for access to a component profile server 12. User 14 interacts with deployment planning system 10 through a graphical user interface 16. Deployment planning system 10 includes a plurality of component profiles stored in a component profile repository. Deployment planning system 10 allows for the deployment of services or a computing system with just the component profiles of the required components. The component profiles are used for deployment testing prior to implementation of the actual system components.
An example of a method for service and role-based software distribution is disclosed in Hellerstein et al. United States Patent Publication No. US 2002/0129356, published Sep. 12, 2002, shown in FIG. 2, and incorporated herein by reference. The method starts at step 20. At step 21, a new software package is introduced. The software package and its description are entered in a service distribution server and stored in a global software repository. At step 22, target regions for distribution of the software package are selected. This step is performed by the software distribution server to determine all the region servers whose service profiles match the service that is going to be provided by the new package. At step 23, the software is distributed from the software distribution server to a region server. For each region in the target set (computed in step 22), the software distribution server prepares a package that is suitable for target machines in that region. This package is then transported to the region. At step 24, the region server determines if each of the potential targets has the appropriate resources (e.g., CPU, RAM, disk space, swap space, etc.). At step 25, the region server retrieves the target roles. At step 26, the software is distributed from the region server to the target machines. At step 27, the results of the software distribution are gathered, and tests are done on the installed software. Installation results are gathered at the region server. At step 28, the region server sends the status of the distribution step to the software distribution server, and the method ends.
An example of a system and method for application management is disclosed in Nakamura U.S. Pat. No. 6,779,028, issued Aug. 17, 2004, shown in FIG. 3, and incorporated herein by reference. Application operation definition storage files are removed from application server computers 30, 32, and 34 and are instead provided on management server computer 36. Management server computer 36 includes application operation definition storage file 38 to systematically manage application computers 30, 32, and 34 via network 40. When an execution request for an application is generated on application server computer 30, application management section 42 looks up the operation definition data of the requested application from application operation definition storage file 38. Application management section 42 executes a to-be-managed application 44. Application management section 42 stores the state of executed application 44 in application current state update file 46. When application management section 42 receives an interrupt message indicating an end event of the executed application, application current state update file 46 is used to store the application execution history. The application execution request is then transmitted to all application server computers in server computer group 48 via network 40. Upon receiving the execution request, application management section 42 looks up the operation definition of the requested application in application operation definition storage file 38. Except when the operation definition of the application indicates that the application operates in the requesting computer, application management section 42 discards the execution request in application server computer 30. The application execution request is then processed using an application management section in another application server computer (e.g., application server computer 32 or 34) by accessing application operation definition storage file 38.
An example of a system and method for software building and deployment is disclosed in Custodio United States Patent Publication No. US 2003/0182652, published Sep. 25, 2003, shown in FIG. 4, and incorporated herein by reference. Software building and deployment system 62 manages the deployment of software and content to a development environment 64, a testing environment 66, and a production environment 68. In the context of providing a commercial web site, production environment 68 contains all of the code and content that hosts the web site for the public. A component is promoted from one environment 60 to another when that component meets the required quality assurance test criteria assigned to each particular environment 60. One or more servers 70 host each environment 60. Software building and deployment system 62 handles all aspects of the deployment of software and content to environments 60. System 62 interfaces directly with one or more source code repository systems 72. System 62 also interfaces with external builders 74, which handle the compilation of source code. Finally, system 62 interfaces with content deployment and replication engines 76 which handle the actual movement of source code and content to environments 60. System 62 controls interactions between source code repositories 72, external builders 74, and content deployment and replication engines 76 so as to manage all changes to one or more computing environments 60. In this way, every change to an environment 60 is handled and tracked by system 62 as a separate release. System 62 is instructed to create a new release in an environment 60 through a manifest 78. Manifest 78 includes the instructions necessary for system 62 to select the correct source material from repositories 72, compile the material, if necessary, using builder 74, and deploy the compiled versions to the appropriate environment 60 using a deployment and replication engine 76. All changes to an environment 60 are initiated by a manifest 78, and therefore each manifest 78 is considered to define a new release for the environment 60 specified by the manifest 78.
An example of a method and apparatus for software deployment is disclosed in Zelechoski et al. United States Patent Publication No. US 2004/0006537, published Jan. 8, 2004, shown in FIG. 5, and incorporated herein by reference. The system architecture includes a total of five layers: business applications layer 90, application bus layer 92, application services layer 94, technology bus layer 96, and technology platform layer 98. Business applications layer 90 includes common application services that provide needed common application functionality to the business applications. Application bus layer 92 provides the necessary communication protocols and configuration information to allow any application to invoke any needed service, regardless of the physical location of that requested service. For example, there may be requests from business application layer 90 to services within application services layer 94. Application services layer 94 includes a number of modularized service engines and common application services, which may be invoked from business application layer 90 or from within the application services layer. Technology bus layer 96 provides access to technology platform layer 98. This layer insulates the business applications and application engines from the physical hardware, the network, and the physical data storage mechanisms. Technology platform layer 98 includes a number of different technology platforms.
As described hereinabove, a number of past approaches exist in connection with software configuration and release management. It would be desirable to improve upon these past approaches and provide a framework for configuration and release management of group application systems software in a software system, providing for configuration and release management both globally to the software system and locally to business units within the software system.